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I. INTRODUCTION 



A. AUTOMATION OF A SUPPLY SYSTEM 

Cut cf a need for a data automation system which would 
handle stock points ar.d inventory control points, grew a 
need for a plan to bring together a number of information 
systems centered around stock point and inventory control 
point applications. The Stock Point Logistics Integrated 
Communications Environment (SPLICE) concept is that plan. 
This concept involves the distribution of a number cf local 
area networks (LANs) which communicate via the Defense Data 
Network (DDN). This thesis will take a brief look at some 
aspects cf the plan. But before examining the SPLICE 
concept, we will compare Local Area Networks and Long 
Distance Networks. 

B. 1CCAI NETWORKS 

A local area network is a data communications system 
which allows a number cf independent devices to communicate 
with each ether, including computers, terminals, mass storage 
devices, printers, plotters and copying machines. A local 
network supports a wide variety of applicatins such as file 
editing and transfer, graphics, verd processing, electronic 
mail, database management and digital voice [Ref. 1], Each 
LAN in SELICE will be uniquely configured and may include 
seme cr all cf the acove components. The question to ask 
concerning local area networks is "What are the characteris- 
tics which make up a lecal area network?" 

According to A. S. Tanenbaura, reference 2, local 
networks have three distinct characteristics: 
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than a few kilometers 



1. A diameter of not mere 

2. A total data rate exceeding 1 Mbps 

3. Ownership by a single organization 

Long distance networks, on the other hand, are networks lake 
DDN. A long distance network is usually owned by a communi- 
cations carrier and is operated as a public utility for its 
subscribers, providing services such as voice, data and 
video [Ref- 1]. The way a communications system will allow 
effective message exchange between different communities of 
users within each local area network is beyond the scope of 
this thesis. 

C. SPLICE AND ITS RELATIONSHIP WITH UADPS-SP 

When SPLICE is examined, we see that it is designed to 
augment the existing Navy stock point and inventory control 
point ADE facilities which support the Uniform Automated 
Data Processing System-Stock Points (UADPS-SP) [Ref. 3]. 
This system was one cf the first attempts at standardizing 
distributed logistical information. The evolution cf 
UADPS-S? will be traced in the following sections. 

1 • Cr^oiri of UALES-S? 

The original concept of the distributed processing 
of supply transactions, along with the maintenance cf stock 
records, was first tested at NSC Norfolk in 1956. Upon the 
successful completion of tests, a number of computers cf 
various sizes and models were installed at a few NSC's 
(Oakland, Eayonne, San Diego), at USD Newport and at NS Y 
Charleston in 1957 and 1958. Prompted by a push for stand- 
ardization cf DOD logistics management systems, in February 
cf 1961, the 3ureau of Supplies and Accounts (presently 
NAVSUP) established a full-time committee to standardize 
procedures as well as equipment at major stock points. The 
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IBM 14 10 computer was selected for Stock Point UADPS in 
January cf 1962 . Open completion of an ADP programming 
training course, each participating stock point was assigned 
the task cf analysing and programming a particular applica- 
tion. Figure 1.1 lists the initial applications along with 



Application 

A 

B 

C 

D 



F 

G 

K 



HISTORY OF STOCK POINT UADPS 
Title 

Requisition History and Status 

Receipts/Dues 

Demand Processing 

Inventory Control File 
Maintenance 

Financial Inventory Control 

Stores Accounting 
Cost Accounting 
Payroll 



Activity 
NSC Bayonne 
NSD Newport 
NSC Norfolk 
NSC Oakland 



NSCs San Diego 
and Oakland 

NSC Pearl Harbor 

NSC San Diego 

NSC Pearl Harbor 
(later changed to 
NSY Long Beach) 



Figure 1.1 Initial Applications. 

the activity they were assigned to in 1962. Tc this list, a 
number of other applications have been added to dare. Of 
course, this was only the beginning of a sysrem which has 
grown and evolved over the years. There have been numerous 
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modif ications and alterations tc the hardware and software 

cf this svstem. There has also been a number of subsystems 
■* * 

added zc it. A list of baseline UADPS-SP application 
segments or significant subsystems have been implemented by 
the activities seen in figure 1.2 

Today, the hardware for the UADPS-SP consists of the 
Eurrouahs medigm sized (E-3500/3700/473G/4800) systems. 
Presently, there are twenty new application systems being 
developed which require considerable interactive and tele- 
communication support. The current UADPS-SP cannot support 
these requirements without a total redesign effort and will 
probably require future replacement of the current main- 
frames [Eef. 3], Nevertheless, as the Navy Supply System 
evolves tc meet the changing fleet needs, ?MSO will adapt 
and adjust UADPS-SP to meet these emerging requirements 
[Ref. 4]. 

2. SPLICE , a ec u put er ne t work in support of U ADPS -SP 

Returning to the SPLICE concept, it has been decided 
that the Eurroughs computers will provide background 
processing functions for large file processing and report 
generation, [Ref. 3]. These are the same computers used in 
the UADPS-SP system. 

According to reference 3, 

SPLICE will be developed, however, usina a standard set 
of minicomputer hardware and software. This standardiza- 
tion is particularly important because SPLICE will be 
implemented at sons'sixtv different Geographical loca- 
tions, each having a different mix cf application and 
terminal requirements. Additionally, each LAN must have 
the capability of comm uni catina vitn other LANs via the 
Defense Data Network ( DDN ) , which is tc be provided by 
the Defense Communications Agency ( DCA ). 

A layout of the local area network ( LAN ) can be 
seen in figure 1.3 . Figure 1.4 , on the other hand, shews 
the logical r.etwcrk concept. Each local area network will 
include the following software modules: 

1 1 



1. Local Communications ( LC ) 

2. National Communications ( NC ) 

2. Frcr.t-End Processing ( FSP ) 

4. 'Terminal Management ( TM ) 

5. Eata Base Management ( DBM ) 

6. Session Services ( SS ) 

7. peripheral Management ( PM ) 

8. Resource Allocation ( EA ) 

The above modules will be divided into those modules which 
perform operating functions and those which support the 
effective use of these modules on the local area network. 

D. STANDARDIZATION CF SPLICE BY DOD 

One of the objectives of DOD in SPLICE has been that of 
standardization. Independent development of local area 
networks would cause problems. The major problem would be 
unnecessary duplication of effort and continued production 
of unique hardware and software. A standard system, or. the 
ether hand, would be more economical to design, develop, 
maintain and operate. For a project the size of SPLICE, 
standardization is the only wise choice. 

E. FUNCTIONS OF THE EATABASE MANAGEMENT MODULE 

As a result of ongoing research in the implementation of 
SPLICE, thus thesis will address these issues involved with 
the design cf the Data 3as e Management Module of the local 
area networks. The functions performed by the Database 
Management Module as outlined in reference 3 will be the 
following : 

1. File creation 

2. File update 

3. Cuery processing and data retrieval 

4. Eata dictionary creation and maintenance 

5. rile catalog creation and maintenance 
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an outline of a 



figure 1.5 gives an outline of a 
management system taken from [Ref. 3]. 



SPLICE 



T« 



4- v - r=- 



back-end daz 
The implement 
Eazabase Management Module has- 



discussed in reference 3 an d xhe conceptual employment 
according to reference 5 is: 



"The concept employed in the recommended 
i irplementation of the database and Terminal 
Mar.acement Resource requirements for SPLICE 
center around a hiahlv d ecenzraliz ed and 
loosely coupled distributed local area 
network ( LAN ) . " 



The processors for each software module within each LAN 
be implemented separately. 

F. SCCPE OF THESIS 

Ie this thesis, a proposed conceptual design of 
database for SPLICE will be presented. It will also ad 
possible problem areas which may be encountered when 
nodule is finally in place and suggestions on hew 
problems may be resolved. Finally, seme hardware sugges 
will be made for the future. 
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HISTORY OF STOCK POINT UADPS 



The following activities have implemented baseline UADPS-SP or significant 
subsystem/application segments: 



UADPS-SP ACTIVITIES 



MCAS Cherry Point 

MCAS El Toro 

MCAS Yuma 

NAF Washington 

NAS Alameda 

NAS Atlanta 

NAS Barbers Point 

NAS Cecil Field 

NAS Corpus Christi 

NAS Glenview 

NAS Jacksonville 

NAS Lemoore 

NAS Memphis 

NAS Miramar 

NAS Moffett Field 

NAS New Orleans 

NAS Norfolk 

NAS North Island 

NAS Patuxent River 

NAS Pensacola 

NAS Point Mugu 

NAS South Weymouth 

NAS Whidbey Island 

NAS Willow Grove 

NSC Bayonne (Disestablished) 



NSC Charleston 

NSC Long Beach (Disestablished) 

NSC Norfolk 

NSC Oakland 

NSC Pearl Harbor 

NSC Puget Sound 

NSC San Diego 

NSD Guam 

NSD Newport (Disestablished) 

NSD Subic Bay 
NSY Norfolk 
NSY Philadelphia 
NSY Portsmouth 
NAVSUBASE Bangor 
NAVSUBASE New London 
NAVSUBASE Pearl Harbor 
ASO Philadelphia 
NPFC Philadelphia 
NARDAF Newport 
NAVMTO Norfolk 
NAVRESUPPOFC New Orleans 
PMOLANT Charleston 
PMOPAC Bremerton 
SPCC Mechanicsburg 
SWFPAC Silverdale WA 



Figure 1.2 Baseline UADPS-SP Application Segments. 
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Minicomputer 
Front-End Processor ••• 




Figure 1.3 



Local Area Network Layout. 
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Operating Functions 




{Memory Module) (Memory Module) 



figure 1 . H Logical network Concept. 
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Minicomputer 
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Fixed 
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•Dictionary 
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Query Function 
(Query Laii^uage) 



Index Function 



Catalog Function 
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Retrieval Function 
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User 
Request 
Messages 
(From 
Terminal 
Management ) 



• Ope n/ Close/ Ca t a l og Files 

• Indexed ketnval & 

Update Messages 



• O{jen/Clo 3 a/Cataioq Files 

• Indexed Retrieval i 
Update Messages 

• Update Records 
(From Terminal 

Management) 



• Retrieved 
Records 
(To Terminal 
Management ) 



» Solid Lines Depict Data Flow 
1 Dotted Lines Depict Control Flow 



• For active files 
•• For inactive files 



I.- Outline c£ a Back -an d Database Manacfomeut Sys~sm. 
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II. THE CONCEPTUAL D ATA BASE SCHEME 



A. DATAEASES PRESENT!! A PART OF SPLICE 

Ths present databases of projects under the umbrella of 
the SPLICE project vary greatly. Nona of the databases are 
standard. It is ere of the purposes of this thesis to 
propose a new conceptual design of a database in the SPLICE 
projec + which will help standardize database operations for 
all sites involved with this project. Since each LAN will 
have a database management module, standardizing databases 
will allow users tc query databases easier from remote 
sites. All queries could be standardized as well. This 
chapter will discuss the conceptual design of such a data- 
base • 

B. DEFINITION OF WHAT A CONCEPTUAL 7IEW ENTAILS 

The conceptual view is a representation of the entire 
information content of the database, in a form that is 
somewhat abstract in comparison with the way in which the 
data is physically stored. ..the conceptual view consists of 
multiple occurences of multiple types of a conceptual 
record... the conceptual view is defined by means cf the 
conceptual schema, which includes definitiens of each of the 
various types of conceptual record [Ref. 6 ] . This jeans 
that the conceptual view of a cataoass shows the overall 
content cf the database. The conceptual schema defines that 
view . 



18 



1 



• Cef ini ticn of SPLICE database 

The database with which we are concerned is a data- 
base which contains information about parts. These parts are 
parts for ships, airplanes, etc. Therefore we can assume 
that basically this database will be a system which invento- 
ries parts. In a database of this type certain information 
is important: 

1. Stock number cr Manufacturer's number 

2. Name of the manufacturer, if it applies 
tc this item 

3. The cost of each item 

4. The quantity cf items available 

5. The location cf the item. The Activity 

6. A brief description of that item. 

This is the minimum amcurt of information which is required 
for an inventory system. 

2 • A to r ca c hes used to P.ecre s en t a P at aba se 

The next thing to decide is the kind of approach tc 
be used tc represent the data in the database. The best 
known approaches are relational, hierarchical, and network. 
The approach proposed in this thesis will be the relational 
approach. The relational approach to data is based or. the 
realization that files that obey certain constraints may be 
considered as mathematical relations, and hence that elemen- 
tary theory about relations may be brought to bear cr. 
various practical picblems cf dealing with data in such 
files [3ef. 7], Notice the relations given in figure 2.1 
These table-like structures are called relations. The rows 
cf such tables or relations are called "tuples" and zhe 
columns are usually called "attributes". One concept that 
relational theory emphasizes and for which there aces not 
seem to be an established data processing term, is the 
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A domain 



concept cf the domain, 
which the actual values 
drawn [Bsf. 7], 



is a 



appearing in 



pool of 
a given 



values 

column 



from 



are 



3 • Fro ros ed Conc eptua l Datab a se Des ign 



In figure 2.1 notice relations cf which the database 
is composed. There are four relations to be considered. The 
first cf these is the Stock-Part relation which includes: 

1. Stock Number (Stock -Hum) - This number 

is the Federal Stock number, a 
thirteen digit number, normally, which 
is assigned to all stock parts. The 
stock numbers could be listed in a 
user's manual which could be placed or. 
secondary storage or online. When the stock 
number list is updated, an updated version 
of the user's manual could be printed. 

(Note: The format of the Federal Stcck 
Number is given below: 

1. Eigits 1—4 Federal Supply 

Cl a ss if icat ion 

2. Digits 5-6 National Ceding 

3ureau Numrer 

3. Digits 7-13 National Item ID 

Number 

Additionally, digits 14 - 15 are 
used for Weapon Systems and Aviation 
parts. ) 

2. Manufacturer Number (Mf-Num) - This is 

assigned tc the part by the manufacturer. 

Since there is no consistent way cf 
numbering parts by manufacturers, it would 
be best if we did net use their numbering 
scheme tc inventory parts. There could 
also be a duplication of manufacturer's 
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numbers because of the inconsistencies 
caused by the lack cf standards used by 
manufacturers. The use of Federal Stock 
numbsrs would eliminate this problem. 

. Manufacturer's Name (Mf-Naiue) - The 

manufacturer's name is given. Some portion 
of it could be abbreviated. 

4. Fart Name (Part-Name) - This gives the 

general category of a part, i.e. rudder. 

5. Quantity (Quantify) - This is the number 

of parts on hand at that particular time. 

6. Cost (Cost) - This is the cost of each item. 

7. Details (Details) - This will give more 

details than the part name. Information 
such as the dimensions cf the part. (Size, 
length, etc.) are given. The differences 
in dimensions will cause the stock number 
tc change, i.e. a 1/2 inch screw has a 
different stock number than a 1/4 inch 
screw . 

8. Becrder Point (3sord-Pt) - This is the 

point at which the inventory is replenished 
for this part. When quantity gets below thi 
point the Vendor' s list must be consulted 
tc reorder stock parts (True for Government 
equipment) . 

9. Weight (St) - This is the attribute which 

gives the weight cf the part in terms of 
pounds, i.e. pcun ds/parts. 

10. Total Weight (Tct-Wt) - This attribute 

gives the total weight cf all parts with 
stock number. 

Note: The key is Stock-Num. 
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The second relation is Local-Net. This relation prov: 
fast access to information indicating the sites where s* 
parts may be found. The attributes included in this r= 
tion are: 



1 . 

2 . 

3. 

4. 



Stock Number (Stock-Num) - Same as stock 

number attribute in the Stock-Part relation. 
Database I.D. (D3-Id) - This is the number 
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date 
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with 
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SELICS site of a particular part, e.g. 
Charleston . 



Note: The key is Stock-Num. 

The third relation is Vender-List. It is a list of 
venders who service this LAN. The attributes are as fell 

1. Stock Number (Stcck-Num) - Same as stock 

given in prior relations. 

2. Quality Vendor List (QVL) - This is the 

list of vendors that government agencies 
are allowed tc procure parts from. This 
list is predefined and could be placed on 
secondary storage. When a list is needed 
it could be printed at that time. 

3. Eld 1 (3id1) - Gives the name of the vender 

who bid on the parts contract. His bid 
is also included. 

4. Eid 2 ( 3 id 2 ) - Same as 3id1. 

5. Eid 3 ( B id 3 ) - Also the same as Eidl. 

6. Eid Evaluation (3id-Eval) - This attribute 

lists the vendor who won the bid. 

7. Purchase Order (Purch-Ord) - This attribute 

gives the purchase order number. If this 
attribute is known, we can collect 



des 

cck 

la- 



all 
ws : 
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historial information or data concerning 
o r de r s . 

8. Lead Time (Lead-Time) - This attribute 

gives the amount cf time which is needed 
between the time the order is placed and 
the shipment is delivered. 

Note: The key is Purch-Ord. 

The final relation is Location-Mf. This relation contains 
information concerning the manufacturer of the part and 
includes the following attributes: 

1. Manufacturer Number (Mf-Num) - Same as 

previously described. 

2. Manufacturer Location (Mf-Loc) - This 

attribute gives the city the manufacturer 
is located in. 

2. Address (Address) - This attribute gives 

the mailing address of the manufacturer. 

4. State (State) - This attribute gives the 

state the manufacturer is located in. 

5. Zip (Zip) - This attribute gives the zip 

code in the manufacturer's address. 

6. Phone Number (Phcne-Num) - This attribute 

gives the phone number, which includes 
the area code, of the manufacturer's 
representative or saleperson. 

7. Salesperson (Salesperson) - This attribute 

gives the name of the person who sold or 

was responsible for the sale in a procurement 

contract. 

Note: The key is Mf-Num. 

Thus, we have a relational database. Its data are net only 
informative but also historical in nature. With purchase 
order numbers, lead time and manufacturer information, it is 
possible to determine when parts were delivered. The 
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could be 
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purchase order number 
details along with its size, 
tions could be used tc help 
system. 



placed 
etc. The 
update parts 
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with 



ttr ibur e 
etwcrk rela- 
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Gelation Stock-Part has an attribute called weight. 
This attribute is the weight of a part in pounds/part. When 
used in conjunction with the total weight attribute, a quick, 
check can be made cc the number (quantity) of available 
parts with this stock number, i. e. dumber of parts = (Total 
Weig ht) / (We iah t in pcunas/part) . If this number is not the 
same as the attribute quantity, there is a possible theft or 



missing part. 

A number of queries may be performed on this data- 
base. The table-lika structures of relational databases make 
the results of operations performed on a database easy tc 
understand. The operations included in this thesis are: 

1. Selections 

2. Projections 

3. Joins 

A selection is an operation which asks for these 
tuples in a certain relation that meet a certain criterion. 
For example, using the Vendor-list relation, the Name and 
Bid cf the vender who made the first Bid on a particular 
purchase order could be selected. 

A projection is an operation which takes a relation, 
removes seme of the attributes, and rearranges some of 
remaining attributes, if necessary. For example, using the 
Local-Net relation, if the Database ID and Site Number were 
needed tc answer a query the information could be printed 
giving the Site Number first followed by the Database ID as 
opposed tc the way it presently appears in the relational 
table. Therefore data could be formatted in any manner the 
user wanted. 
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Finally, there is the join operation. A join is 
operation which combines data of two or more relations-, 
example, using the Stock- Farts and Location-Mf relations, 
the addresses of manufacturers with a particular stock 
number could be found using the join operation in conjunc- 
tion with the selection operation. All of the above opera- 
tions can be used to answer a query for the user. 

The relations in this database are rather long, but 
they are designed that way in order to avoid having many 
joins performed on relations. Fach relation gives as much 
information as is necessary for that particular relation. If 
all cf the information is not needed, selections car. be made 
cn which attributes should be projected by the user. The 
user would have nc need of joining numerous 
together in order to get the information he needs. 
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III. EHCEIEfiS IN THE LOCAL AREA NETWORK DA TAB ASE MANAGEMENT 

MODULE 

A. POSITIVE CHARACTERISTICS OP A DISTRIBUTED SYSTEM 

The local area networks in the SPLICE system are made cf 
distributed systems. Some of the characteristics cf a 
distributed system are given below. First, minicomputers are 
used in these systems. Secondly, distributed systems give 
users more individualized control over processing. The sche- 
duling of jobs and quality of services can be determined by 
the user himself. Finally, distributed systems can be mere 
readily tailored to organizational structures. Since no two 
organizations are exactly alike, flexibility is important. 

B. NEGATIVE CHARACTERISTICS OP A DISTRIBUTED SYSTEM 

There are also negative characteristics cf distributed 
systems. First, the procedures required to implement distri- 
buted systems are complex. Communications facilities must 
be procured and computers must be connected. Data compar- 
ability alsc must be ensured. Thus, a number of problems may 
occur in a distributed environment. These problems and 
possible sciuticns will be discussed in the following 
sections. 



C. EBCBIEM AREAS 

1 • Access Centre! ana Secur ity 

Cne cf the biggest problems in a distributed system, 
as in any computer system, is access control and security. 
If data are online and there are multiple users who may be 
able tc access that data, care must be taken as to how data 
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are altered. It is very important that the accuracy of data 
are preserved. Data can be altered in two ways: 

1. Accidentally, through typing errors or 
programming errors 

2. Intentionally, through malicious misuse 
cf a database. 

To prevent incorrect data from being stored in a 
database or being read by unauthorized personnel, there are 
two areas cf concern. According to Ullman, these concerns 
are : 

1. Integrity preservation, and 

2. Security. 

Integrity preservation is guarding against a nonmalicicus 
error. This can be done by writing a program in such a way 
that it checks for ccnf lie ting records before anything is 
completed (updates, inserts, etc.). Security, cr access 
ccntrcl as it is sometimes called, is concerned with 
restricting access of users. Only those persons with a ’’need 
to know" should have access to particular data. Therefore, 
modification and alteration would only be performed by 
authorized personnel. These precautions, if taken, would 

allow more ccntrcl over data and thus preserve the accuracy 
to a greater extent. As a bear minimum, all online files 

should have access control using account numbers and accom- 
panying passwords. These passwords would restrict the users 
to data which is needed only by him or her to get the job 
dons (for example, read-only passwords) . This is needed gust 
for ccntrcl cf everyday usage of the database. A number of 
additional precautions can be taken to further ensure that 
data are lass vulnerable. Encryption, the coding cf data so 
that it is unintelligible, is being used in the SPLICE 
system as a further precaution for the protection cf data. 
This is not effective, however, unless the proaratrs which 
encrypt data are protected from would-be infiltrators. 
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A problem associated with all database systems is 
that cf concurrent updates. This is the problem which may 
cccur in any system which has more then one user updating 
the same file at the same time. In a distributed system, 
where there are concurrent executions, there is always the 
chance of there being problems with livelock and deadlock. 
Livelock is a situation where there may be one or more 
processes waiting on a locked item. Using a first-come- 
first-served strategy cf locking items usually resolves this 
problem. Afterwards, all locks are released. Deadlock is a 
situation in which each member of a sat of transactions is 
waiting to lock an item already locked by another transac- 
tion in the set. Since each transaction of the set is 
waiting, it cannot unlock other transactions. Therefore ail 
cf them wait indefinitely. Detection and prevention are two 
ways of handling deadlocks. 

Leeks should be placed cr all items to be updated 
before updates are cone in order to solve the concurrency 
update problem. Certain transactions prevent other transac- 
tions from accessing a data item until that item is 
unlocked. Therefore, ether users cannot access that portion 
cf the database. This is particularly important in distri- 
buted environments because cf the various locations cf data. 
If the locking approach is used, the items to be locked 
should be fairly larce, maybe even entire relations. This 
would reduce some of the costs associated with the locking 
mechanism . 

When viewed ever the entire SPLIC 2 system, databases 
are obviously geographically distributed. For the purposes 
of maintaining adequate control over cataloging files and 
maintaining the integrity cf related files in the database 
(synchronization of updating procedures), the database 
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functions ars centralized within each LAN. Other than the 
fact that seme files will remain on the Burroughs Hosts and 
some files will migrate to an interactive DBM, there' is no 
reason to provide for the distribution of databases within a 

LAN [fief. 3]. 

3 • S vs t em Crashes 



Cne problem which needs consideration is hew to 
handle or prevent system crashes, when a computer fails, all 
or part of a transaction may have been completed. There is 
no sure vay to tell exactly what has happened. For that 
reason, it is essential that backup copies of files be made 
periodically. For larger databases, copies can be made less 
frequently than smaller ones because of the amount of time 
it takes for copying large databases. During recovery after 
a failure, a determination has to be made as to which tran- 
sactions should be repeated. For this reason, a leg or 
journal is needed which will contain information concerning 
all chances to the database since the last backup copy was 
made. Recovery from failure is particularly a problem with 
online systems. There may be no copies of the transactions. 
Therefore, it may be very difficult to recreate the transac- 
tions. The reprocessing may net repeat tae exact processing 



sequence. 

Finally, consideration should be given to preventing 
and handling system crashes and of dealing with whether a 
transaction has been ’’committed" or not. This is the point 
at which a transaction is considered complete. When transac- 
tions must be "redone" or "undone", a log or journal which 
contains those which have committed will assist in recon- 
structing the database. According to Oilman, [Ref. 6] on a 
could define a two-chase commit policy which would operate 
as follows: 
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1. A transaction cannot write into the database 
until it has committed. 

2. A transaction cannot commit until it has 
recorded all its changes to items in the 
journal. 

Ail unlocking is done after the committed transactions have 
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(2) - Cer.t rali z ed or Par t it i oned . 

It Is not easy to know exactly where to 
put global data. The first consideration is whether it 
should he centralized or partitioned. If it is centralized, 
one computer in the distributed network stores the data. A 
request is sent to this computer when global data is needed. 
Partitioned data, however, is spread over several computers. 
If data is needed , its location has to first be determined 
and then accessed. 

The advantage of centralized data is that 
every node knows the location of data. This is the approach 
which will be used in the SPLICE system for the Database 
Management Module in each LAN. This makes the system simple. 
The concurrent update problem would only be handled by one 
processor. However, if global data is needed, it is possible 
that a performance bottleneck will develop when accessing 
data from one computer. Partitioned data would net cause 
this kind of problem. 

Reliability also has to be considered. 
With centralized data, if the one database computer fails, 
all nodes in the local network would have to discontinue 
processing. When global data is needed in a partitioned data 
system if one node fails, all ether nodes in the network 
could continue processing. Unfortunately, updates cf parti- 
tioned data are much harder to control [Ref. 8], A central- 
ized system can be configured to continue operation, in the 
case cf failure, by using redundant hardware and software, 
combined with mirrored disk operation and checkpointing. 
This will be the way SPLICE will handle this problem. 

(2) • Re p licat e d cr Nonr epli ca ted . 

There should be a number of copies of the 
data s~cred in the network. To replicate centralized global 
data, the entire collection of global data is stored at 
several locations in the network. When this is acne, :h s 
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nodes need only keep lists of the computers having -_he 



repl 


icat 


s 


d 


data . 


Th 


ey d 


o n 


Ot 


ns 


ed di 


rect 


oris 


■ s th 


a 


t she w 


the 


lcca 


tier. 


c 


0 


f parti 


cu 


lar 


ki 


nd^ 


s 0 


f da t 


a; 


ail 


of 




he data 


is 


loca 


ted 


a 


t 


each of 


4. 


he n 


ode 


s • 


A 


Iso, 


repl 


icat 


ing 


g 


lobal data 


elim 


ir.at 


e 


c 


the bet 


tl 


enec 


k a 


nd 


re 


liabi 


11 ty 


pro 


blem 


c 


discus 


sed 


> 

O 

-O 

fli 


<5 , 




tu 


t intro 


du 


ces 


th 


e 


pr 


oblem 


cf 


con 


cur r 


3 


nt upd 


ate 


cont 


rcl 


c 


Be 


f. 8]. 




































Wh 


en 


da t 


a : 


L S 


part 


iticr.ed 


or 


r 


eplicat 


ed. 


each 


nod 


c 




m us t ha 


ve 


ac 


css 


s to 


a di 


rect 


or y 


that 




gives 


the 


loca 


tion 




0 


r lo ca 


t 2. 


CHS 


of 


eac 


h t y 




c f 


data 




[ Bef . 


83* 


Ther 


efor 


3 


0 


wh e n 


a 


user 


— T* 
- 


ies 


to ac 


cess 


gio 


bal 




data. 


the 


cper 


a ting 


s 


y st em 


or 


DBM 


S C 


alls 


upon 


the 


dir 


set 0 


r 


y to f 


ind 



the location of than data. 

Finally, Kroenke states that the greatest 
amount of flexibility can be found with the replicated, 
partitioned storage of data across a network. However, 
control is much more difficult. More complexity is also 
added to the operation of the network. 

When updating data in a system that has 
replicated data, there is an issue which should be consid- 
ered. In a centralized, non replicated data system, an appli- 
cation program can lock records before they are used. Ihe 
lock only involves data in a single computer, whereas with 
replicated data a lock would have to be placed on all 
computers with the global data item. The problem with this 
is that if locks are applied simultaneously, one user could 
possibly have the record locked on one computer while 
another user has the record locked on another computer. 
Neither user has complete control because both locks are in 
place for two different users. The system has tc resolve 
this conflict. This process can waste a lot of time. 

2 v er. nonr eplicated , partitioned data can 
cause problems. If a transaction is to be applied tc several 
different records. There is no problem if this update is 
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done cn ere computer. If some of the data are on diff 
computers, however, there could be owe users locking 
ether cut. 

These are concurrency problems. The 
luticn cf these problems is an active research area, 
though the concurrency updating problem is of concern, 
scope of this thesis dees not include the resolution cf 
problems. 



each 

reso- 
E ven 
the 
such 



34 



IV. THE DATABASE MACHI NE AS AN ALTERNATIVE DESIGN 

A. GE0H1H POTENTIAL CF SPLICE PROJECTS 

The database computer (DBC) or the database machine 
(DBM) , as it is sometimes called, should be considered as 
cr.e cf the hardware alternatives for i mplemer.tating the 
Database Management System (DBMS). By offloading DBMS func- 
tions from the host application computers to DBM, applica- 
tion processing speed is increased and SPLICE application 
growth can be more readily absorbed. 

E. CONVENTIONAL COMPUTERS 

1 . Ces ioned using Large, Com pl ex So ft war e 

large databases of the future may need a DEM. 
3ecause the database machine is a special purpose machine, 
which can handle DBMS efficiently, large databases of the 
future will more than likely be managed by database machines 
as opposed to conventional database management software. 

In the following paragraphs, DBMs will be examined. 
Actual models of DBMs will be presented and the different 
approaches tc DBMs architectures will be discussed. 

2 • Designed to Ac ce ss Data b v ?h vsica l A ddr e ss 

Conventional computer architect ures and applications 
have been designed to refer to physical addresses in order 
to address data. With the increasing number of applications 
which are centered around information storage and retrieval, 
the conventional systems are unable to retrieve information 
by content. This inability to handle content addressing has 
lead tc interest in computer archit ectures which are mere 
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efficent in information storage and retrieval applications. 
One cf the solutions to this problem is the database 
computer. The database computer can be incorporated into a 
system ir. cne of four ways: 

1. Eack-end processor for a host 

2. Intelligent peripheral control unit 

2. Storage hierarchy 

4. Network node. 

These approaches are independent of each other, which may 
suggest that more than one approach could be included into a 
system's architecture. 

C. DATABASE COMFUTBB APPROACHES 

1 • !§ 5 i 5 m*d Proc essor 

The back-end processor is a general purpose computer 
which is thought cf as a master-slave configuration. High 
level access requests are passed to the back-end processor 
by the best computer. Access validation, management of 
storage, update lockout, response formatting, and I/C opera- 
tions are all performed by the back-end processor. After 
the back-end processor is finished, it passes the response 
tack to the host. 

2. I ntell igent ? erioh e ral 

The intellignet peripheral control unit works in 
conjunction with a mass storage device. Highly repetitive 
data accesses are moved to a mass storage controller to 
avoid high overhead on the host hardware and software. 
Functions like device scheduling, head positioning, data 
recovery, searching, sorting and error correction are 
performed by the intelligent peripheral control unit. 
Functions like sequential associative access and parallel 
read (or. a disk) can also be implemented. ( Note: An 
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associative computer architecture allows data to be accessed 
directly by value without physical addresses.) 

3. Storage Hierarchy 

The storage hierarchy is similar to the cache memory 
approach in that both are concerned with the locality of 
data. The locality cf access is such that data already used 
or data near other data which has been used, is very likely 
to be accessed in the near future [Ref. 9]. This character- 
istic can be used to speed up the access of data ir. a data- 
base. The database cache could oe inserted in the system 
between main storage and disk [Ref. 9 ]. If implemented by a 
sequential access device, such as CCD or bubble storage, 
access time would be less than 1 msec, if data is located in 
the cache. Otherwise, the request would take longer. The 
fact that data is managed on the laast-rscetrly-used basis, 
ensures that most of the active data resides in the fast 
access CCE cr bubble storage. 

U • Nod e 

According to reference 9, The "network node", yet 
another approach to a database computer, is a general 
purpose computer which communicates with several other nodes 
in the system, most frequently using a data communications 
protocol and serial channels, but possibly using I/O chan- 
nels. The benefit in of this configuration is that several 
nodes (hosts) can access a single shared database, thus 
avoiding replication cf the data. It is implemented on a 
general purpose system, host and back-end, or processor or 
host and intelligent control unit. 
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D ATAE ASE TECHNOLOGY 



In the past cecade, the Dataoase Management System has 
become mere popular. There are many gains to be made through 
the use cf database technology. The Database Management 
System relieves the application program of many tasks. Yet, 
the Database Management System has had its drawbacks. 
Typically, the software laden database management system has 
been large in size and complex in structure, which net only 
overtaxes the host hardware, but also stresses the host 
operating system [Ref. 10]. Large and more sophisticated 
applications began to demand more speed, capacity and 
retrieval flexibility on general purpose computers. 
Therefore, it's not surprising that a way to alleviate seme 
cf the demands on general purpose computers has been sought. 
As technclcgy improved it was clear that a mere efficient 
form cf back-end processor could be developed as a "database 
machine", ere specially designed to manipulate and access 
data with, more flexibility than conventional computers 
running general purpose software [Sef. 11]. 

E. INITIAL RESEARCH CF DBMS 

Research on the DEM concept started at Bell Labs in the 
early seventies as work cn a "back-end" DBMS (Database 
Management System) using general purpose computers in a 
dedicated environment [Ref. 11]. As a back-end machine, the 
E3C (Database Computer) attempts to achieve high performance 
and lew ccst [Ref. 10]. Originally, the five goals of the 
DSC were: 

1. To design a machine with the capability cf 
handling a very large online database cf 
10 bytes or greater (The DBM is usually 
net ccst effective on a smaller database) 

2. To build a database computer today (1979) 

3. Tc have the DBC compete in a favorable 



38 



I 



manner with the existing DBMS as far as 
system throughput and cost of database 
storage were concerned 

4. To make security an integral part of the 
DBC design 

5. To provide a repetoire of very high-level 
commands in order to sufficiently interface 
with front-end computers and support 
database management applications. 

F. MCDEIS CF DBMS 

1 . IDM Fa mi ly 

a. ID M 500/1 ar.d I DM 500/2 

Britton lee, Inc., a company in Lcs Gates, 
California, has developed a number of relational database 
machines. Among those developed are the IDM 500/1 and ID M 
500/2, relational intelligent database machines, as well as 
the IDM System 300/6C0, a relational database management 
system. 

The IDM 500/1 was the first high-performance 
Intelligent Database Machine (IDM) on the market. It serves 
as an auxiliary processor to cn^ or more host computers and 
is dr iv =n by a high-level query language which is resident 
in the host. It handles the relational database tasks and 
manages dedicated database disks. The IDM 500/1 has rocm fer 
expansion for medium to large database applications ar.d is 
programmed to optimally perform retrieving, updating, 
sorting, etc. The IDM 500/2 is basically the same machine 
but it is a high-end custom-designed 10 MIPS database accel- 
erator model. It handles transactions 2 to 10 times faster. 
A full cc aplement of database management functions performed 
by both members of the IDM family are listed below: 
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1. Easic Commands - Host formatted tc IDM 

specifications, which create and destroy 
databases, relations and indicies to data. 

Also appending, retrieving and replacing 
data are handled in relations. 

2. Integrated Data Dictionary - Data dictionary 

relations are automatically maintained 
or. information about data. 

3. Transaction Management - Ensures that 

u ser- s peci f ied transactions are fully 
completed or backed out in the event of 
a failure. 

4. Concurrency Control - Allows multiple users 

tc safely access the same database 
s i mu 1 1 an eo u sly . 

5. Access Control - Protects data by using such 

features as deny/permit access privileges 
and read/write locking of shared data. 

6. Audit Logging - Maintains check pointed audit 

or transaction logs for auditing, backup 
and recovery. 

7. Backup and Recovery - Online dump facility 

supports backup of disks, databases and 
transaction logs to disk, tape and the 
host. The database is recovered via a 
load and transactions are rolled forward. 

8. Random Access Files 

9. Stored Commands - Minimizes execution time. 

User-defined stored commands are featured. 

All these functions can be seen in 4.1 The architecture is 
modularized and expandable. In figure 4.2 the data 
processor, main memory, disk controller and tape controllers 
(optional) are shown. 



40 



Host interfacing is provided by Doth parallel IEEE-438 and 
serial RS232C host interface modules (Up to 8 hosts). The 
system alsc has extra expansion slots for future growth. The 
IDM 500/2 has an extra function, the Database Accelerator. 
It is custom-designed and has an instruction set which 
optimizes relational database processing. 

fc. IDM 300/600 

The IDM System 300 and IDM System 600 are 
complete relational database management systems for DSC VAX 
users running VMS or UNIX, and for PDP-11 UNIX users, 12 
Eoth combine an Intellignet Database Machine (IDM) , of 
Erittcn Lee, with end-user software tools in the host for 
database applications. Included in the software are: 1) data 

entry facilities 2) an ad hoc online query language 3) a 
report writer 4) program language interfaces for FORTRAN, 
COBOL and C (programming language) 5) a full complement of 
Database Administration utilities. The IDM System 30C/600 
architecture can be seen in figure 4. 3 

The functions performed by the IDM System 
300/600 are the same as those listed above for the IDM 500/1 
and IDM 500/2. There is an additional function, however. 
That function is Multiple Host Support. It can be expanded 
to allow several hosts to access its databases. This access 
is provided by the IDM System 300/600 UNIBUS Interface 
Packages. Figure 4.4 shows the system architecture. Figure 
4.5 shows a summary of the maximum IDM capacities. 

2 . i C B P 86/440 

Another consideration is the Database Processor 
(iDBP 86/440) by Intel. It is a microprocessor-based rela- 
tional database management system. Functionally, it is a 
mass storage controller for one or more hosts. Software and 
specialized hardware are included in the database management 
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system design. It is positioned between -ha hcst(s) anc a 
sat cf dadicated disks. 4.6 shows the system architecture. 

The iDBP provides a database management system 
"kernel* 1 which supports relational, hierarchical and network 
databases. It also provides concurrency control, security, 
integrity and recovery mechanisms for sharing cf data. In 
addition to traditional, record-oriented files, the iC3P 
also manages unstructured files which may contain text, 
graphics, digitized voice or digitized imaaes [Ref. 13]. 
Even though the i D B E 36/440 is the first of a family of 
database machines by Intel, it wall continue to be enhanced 
as the new VLSI component is integrated into it in the 
future. Figure 4.7 gives the configurability cf the iDBF and 
its system capacities. 



3. NCAH 

I he final database machine to be examined is called 
NOAH, produced by HER Systems Inc. NOAH is a relational 
database machine which provides a modular architecture . 4.8 

gives NCAfi’s hardware configuration. Seme of NOAH's software 
modules reside on processors dedicated to database manage- 
ment and auerv language functions while others reside cr. the 
general purpose host. The functions performed by NOAH are: 

1. Query language { SQL/NO AH) 

2. Integrated Data Dictionary 

3. Security 

4. Fee every 

Figure 4.9 gives specifications and configuration 

information . 

These were, cf course, only a few of the database 
machines which have been designed and developed in the last 
few years. 
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G. EXPECTED PERFORMANCE OF DECS 
1 • Advantages of CBCs 

A large number of database management functions are 
implemented in hardware. Since this is the case, EBC 
computers are expected to perform quite a bit better +han 
the computers which provide these functions in software. 
Software security enforcement may also be absorbed in hard- 
ware . 

An existing database may be supported or. the EEC by 
converting the database to conform to the DEC representation 
of data. This one time conversion is known as database 
transformation [Ref. 10]. The DBC manufacturers claim that 
nc reprogramming of the database management application is 
necessary, unless the user wishes to reformat his data. An 
interface will translate the database management calls into 
DEC commands. The interface requires a small amount cf soft- 
ware because EBC commands resemble high-level data 

languages. This process is known as query translation. -The 
EBC interface package resides in the front-end computer. The 
interface, together with the database computer, replaces a 
full-scale software database management system and its 
conventional disk storage [Ref. 10]. The application 
program, however, is net replaced. 

According to reference 10, 

It is estimated that in supportrnc these aoolicat ior.s on 
the DBC, the database storage requirement' is as muen as 
1.5 or 2 times that in a conventional system. This 
excess storage requirement, however, is a c ecu at sly 
offset by one or mere orders of macitude imorevement ir. 
the execution time cf user transactions. Furthermore, 
the st ora qe requirement for the rndicies decreases bv 
one or mere orders cf maanitude. Finally, the size cf 
the software (i.e. the DBC interface) is expected to be 
several orders of magnitude smaller than conventional 
database management software. 
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Today, software for mainframe computers rs 
handling problems such as recovery from failure, concurrency 
control, and integrity validation. If the DBC handles such 
problems, it would relieve the mainframe system of many of 
the database software functions. 

2. C is advantages of DBCs 

Ir. spite of all the potential benefits provided by 
database computers, there are seme disadvantages which must 
be pointed cut. These disadvantages are the following: 

1. EEMs increased system complexity 

2. EEMs load balancing is difficult 

2. EEMs will create training and conversion 

requirements for users 

When a system is designed, complexity, functionality 
and cost must be considered. A decision has to be made as to 
which of these issues is most important to an organization. 
The back-end processor and its associated software adds cost 
and complexity to the total computer system [Ref. 14]. The 
decision which must be made by the organization, however, is 
whether *hese two added dimensions will pay for themselves 
ir. the future. Also to be considered is the fact that two 
hardware ar.d software systems will have to be maintained. 

Another consideration is the fact that with conven- 
tional hosts, it is possible to oaiance the lead between 
computers. Once a DBM has been acquired this is r.ot 
possible, since the EEM is dedicated to one task, database 
management. However, it must be mentioned that one of the 
main reasons for acquiring a CBC is to offload DBMS from the 
host tc the CBC. 

Finally, if an organization has never used a data- 
base computer before, there will be a considerable amount of 
time which will be needed for training and system conver- 
sion. The organization must consider this and incorporate 
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its effect into the time 
become operational. Also, 
resistance *o the new tec 
These are a few of the pos 
tion could encounter as a 
to include the database com 



it will take for the system to 
the organization must anticipate 
hnology from experienced people, 
sible disadvantages an crgar.iza- 
result of changing its operation 
puter concept. 




Figure 4.1 Database Management Functions of the IDH 500. 
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Figure 4.2 Architecture of the IDS 500/1 and 500/2. 
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Figure 4.3 



IEM System 300/600 Architecture. 
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The IDM System 
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Figure 



SUMMARY OF MAXIMUM IDM CAPACITIES 



SPECIFICATION 



IDM 200 



Base Configuration 



5 board set 

in 7 slot chassis 



Expandable to: 

IDM Memory 
Dish Storage 
Tape Controller 
I/O Controller 

AS- 2 32 serial and / or 
IEtE-48u parallel 
Database Accelerator 



1 Mbyte 
*1 SMD disks 
8 transports 



24 devices 
No 



IDM 500 



5 board set 

in 16 slot chassis 

6 Mbytes 
16 SMD disks 
8 transports 



64 devices 
Yes - Optional 



Relational DBMS Capacity 

Number of databases 60 

Relations per database 32,000 

Attributes per relation 250 

Tuples per relation 2 billion 

Tuple Width 2,000 bytes 

Indices per relation -55 

Attributes per index 15 

Index type B*tree 



50 

32.000 
250 

2 billion 

2.000 bytes 
255 

15 

B'tree 





Number of Users 


128 


4,006 





4.5 



Summary of the Maximum IDM Capaci 
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Figure 4.6 The iCBP Systan Architecture. 
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Figure 



1 

I 

I 

Options Available 

640 K hues of RAM 
1C24K bvtes of RAM 



Host interfaces: 


One to sixteen serial links (RS232) 


(may be intermixed 


One to four parallel links (IEEE 488) 


per system) 


One or two Ethernet links 


Mass storage interfaces: 


One to sixteen SMD'Compatible or Winchester disk drives 
One to four SMD or Winchester disk controllers 
One start/ stop tape drive 



System capacity 

Maximum number of files 32,767 

Maximum file size 263 Mbytes 

Maximum number of databases 255 

Maximum number of files/ database 255 

Maximum number of items/ record 127 

Maximum number of concurrent sessions 254 

Maximum structured record sire 8,1 Q 2 hues 

(equals maximum nape sire) 



Configurability 

System Feature 

Memory sire 



1 Configuiabilit y of the iDBP and it f s Sysxem Capacities. 
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NOAH'S 



Hardware Configuration. 



Figure 



4.8 





Preliminan N aerifications 



Database Type: Relational 
Maximum data capacity: 32 billion bytes 
Typical processing rate: 

2-5 transactions per second 
1025 with Database Accelerator Option 
Maximum numoer of databases per IDM: 50 
Maximum numoer of relations (files) per database: 
32.000 

Maximum number of domains (fields) per relation: 
250 

Maximum number of tuples (records) per relation: 

2 billion 

Maximum tuple width: 2000 bytes 
Data tvpes: 1. 2. 4 bvte integers 

1* *255 byie variable lengtn character fields 
1031 digit packed decimal 
4. 8 b\ie floating point 
Maximum number of clustering indices per 
relation: 1 

Maximum number of non-clustering indices per 
relauon: 255 

Maximum number of domains (keys) per index: 15 
Index type: B tree 

Configuration Information 



Base configuraiion: 

• Query Processor 

8 Channel Processor Boards 
Daiaoase Processor Software Loader 
^QL Noah Querv Language 
Database Management Utilities 
Interface Software for Supported Host(s) 



lb Sloi Chassis. Power SuppU and Bottom - 
Plane 

• Database Processor 

Memory Timing and Control Board 
Memory Storage Board (256k hues) 

Disc Controller (supports up io 4 Storage 
Module Drises) 

Serial or Parallel I/O Channel Board 
16-slot Chassis, Power Suppl> and Boiiom 
Plane 

Oplions 



Additional Query Channels 
(Supports Up to 12) 

X2 Query Channel Upgrade 
Report riter/ Query Channel (Available 9/83) 
"488 IEEE Host/Noah Upgrade 
488 IEEE Internal Noah Upgrade 
Tape Controller and Tape Drive 
(Supports up to 8 tape drives) 

Database Accelerator (Tvpicallv improves 
performance by a factor of 10) 

Memory (256k bvte Arrav Boards) - up to 
3 Megabytes of Storage 

Physical Size 52” H X 30” D X 24” W 

Noah Enclosure 19” W X 22” H X 2?” D 

Weight: Noah Enclosure 150 Lbs. 

Max. 120 Lbs. Avg. 

Cabinet bav 100 Lbs. 

IDM 170 Lbs. Max. 150 Lbs. Asg. 

Electrical Spec. 900 W Max. 120 V 60 Hz 
AC r I0«t 



Figure 4.9 Specifications and Configuration Information. 
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V. CONCLUS ION S 

Distributed processing and computer networks are 
enabling computers to use programs and data stored ir. 
computers at different locations. The SPLICE project is cr.e 
of these projects in which these advances will be incorpo- 
rated. Growth in communications, minicomputers and micro- 
computers is making the use of distributed processing 
possible. Many of the jobs which used to be done cn large, 
heavily shared computers can now be done or. stand alone 
minicomputers or mic i cccmpu tens (Ref. 15]. The advantages 
of distributed information has received increasing atten- 
tion. The recognition of these advantages has provided 
impetus to work on distributed systems. However, the 
complexities of such systems must be investigated and 
resolved if these systems are to work effectively. 

This thesis only covered a small portion cf SPLICE, the 
Database Management Module. A conceptual design of the data- 
base for SPLICE was given. Since the database will be one 
which will contain data on Supply parts, the attributes 
given in each relation ware carefully chosen to reflect 
information needed in an inventory system. The relations 
which were designed are long. Shorter relations can be 
joined tc produce the same attributes. Joins, however, can 
be time consuming. Therefore, the longer relations, which do 
not take as much time to provide the attributes needed to 
answer a query, were utilized. 

Among the problems of a distributed system are access 
control and security. The use of encryption devices, user 
accounts and passwords are the minimum in security features 
which must be ir.cor ccrated into SPLICE. 






Concurrent updates in a distributed ir.vi:cr.n?r.: car. 

cause a problem. However, deadlocks and livelccks car 
possibly be handled by using locking strategies. Besides -he 
concurrent update problem, recovery from crashes must be 
considered. When a system fails, the number of transactions 
which were completed is unknown. There must be some type of 
logs cr journals which will help to determine not only which 
transactions were completed, but also the source of the 
failure. All of this has to be considered ir light cf the 
fact that ether systems in a distributed netwerk must 
continue tc function reguardless of the fact that one 
computer has failed. 

Iccking data is another problem within a local area 
netwerk. Whether data is local or global, centralized cr 
partitioned, will determine the magnitude of the problem. 
Accessing data as well as updating data can be a big problem 
especially if locks must be placed on the data. 

Finally, alternative hardware considerations fer SPLICE 
were discussed. The database computers were proposed as an 
alternative to conventional computers. The different 
approaches tc database computers were given (back-end 
processor, intelligent peripheral, storage hierarchy, 
netwerk node) along with a brief description cf each. Also, 
several models cf database computers were presented with 
their functions and architectural configurations. From the 
inf o r ma ti cn presented on these database computers, all of 



which were relational, we 


found thac 


they have 


f 9 


which could be very useful 


for SPLICE. 


The fact f 


ha 


are able tc directly acces 


s the center 


it of a data 





well as being able tc offload database management systems, 
make them very attractive alternatives. Some of the database 
computers are even able to interface with existing data- 
bases. We must, however, take into account the disadvantages 
cf database computers. All thing considered, database 
computers seem tc be a very viable alternative for SPLICE. 
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